Ticket ENG-3009

Description Of Changes

Fixes a bug where the Save button in EditSSOProviderModal was permanently disabled after creating an SSO provider. Users could not save any edits to an existing provider.

Root cause: The GET endpoint intentionally omits client_id and client_secret from responses (sensitive fields). The Yup validation schema required both, so the form was always invalid — disabling the Save button even after editing other fields like name.

The fix makes credentials optional in edit mode via a validation schema factory, removes the required asterisk from credential fields in edit mode, and strips empty credential values from the PATCH payload so the backend (companion PR ethyca/fidesplus#3284) can preserve the existing encrypted values.

Dependency: Requires ethyca/fidesplus#3284 to be merged first.

Code Changes

• Converted SSOProviderFormValidationSchema to getSSOProviderFormValidationSchema(isEditMode) factory in SSOProviderForm.tsx; client_id and client_secret are required only in create mode
• Added const isEditMode = !!openIDProvider and threaded it through form validation, submit handler, and isRequired props on credential inputs
• In edit mode, strips empty client_id/client_secret from the PATCH payload before submission so the backend preserves existing encrypted values

Steps to Confirm

1. On the SSO Providers settings page, create a new provider (e.g. Google) with any client_id and client_secret
2. Click the edit (pencil) icon on the newly created provider
3. Change only the Name field
4. Verify the Save button is now enabled and clickable
5. Click Save — verify the name updates successfully without requiring re-entry of credentials

Pre-Merge Checklist

• Issue requirements met
• All CI pipelines succeeded
• CHANGELOG.md updated
  • Add a db-migration This indicates that a change includes a database migration label to the entry if your change includes a DB migration
  • Add a high-risk This issue suggests changes that have a high-probability of breaking existing code label to the entry if your change includes a high-risk change (i.e. potential for performance impact or unexpected regression) that should be flagged
  • Updates unreleased work already in Changelog, no new entry necessary
• UX feedback:
  • All UX related changes have been reviewed by a designer
  • No UX review needed
• Followup issues:
  • Followup issues created
  • No followup issues
• Database migrations:
  • No migrations
• Documentation:
  • No documentation updates required